Hi,
newly I was confronted with the possible restriction of searching ability of the 'contains' DXL function:
It was not possible to search for pattern begins with "." (dot)
Example: -1!=contains(buf, pat, 0) , where pat = ".tst"
After removing the dot from the pattern, worked fine.
Is it right that contains does not able to search for such kind of patterns?
Or I'm doing something wrong?
Thanks in advance,
vasgyuszi
vasgyuszi - Mon Feb 22 08:23:17 EST 2010 |
Re: DXLs 'contains' limited searching abilities?
ePiallat - Mon Feb 22 09:01:07 EST 2010
Hi,
From DXL manual:
contains
Declaration
int contains(Buffer b,
char ch
,int offset)
int contains(Buffer b,
string word,
int offset)
Operation
The first form returns the index at which the character ch appears in buffer b, starting from 0. If present, the value of offset controls where the search starts. For example, if offset is 1, the search starts from 2. If offset is not present, the search starts from 0. If ch does not appear after offset, the function returns -1.
The second form returns the index at which string word appears in the buffer, starting from 0, provided the string is preceded by a non-alphanumeric character. The value of the mandatory offset argument controls where the search starts. If word does not appear after offset, the function returns -1.
If you want to match something like "foo.tst", it will not work, because 'o' is alphanumeric.
To search a buffer, use the "search" function. And because it searches Regexp patern, do not forget to escape the dot:
Example:
false!=search(regexp pat, buf, 0)
, where
pat = "\\.tst"
- Éric
|
Re: DXLs 'contains' limited searching abilities?
llandale - Tue Feb 23 13:19:54 EST 2010
The 'contains' for 'strings', I guess, is for some sort of syntax token parsing; and I never use it. 'Must be preceeded with white space' is a big restriction.
I dislike Regular Expressions since I believe they are slow and wasteful. I've got a rather complicated search function, that first uses the 'contains(buf, char, offset)' for the first character of the search string, then compare byte-by-byte bytes from the buffer with that of the search string. 6 or 7 years ago when I wrote it, it was the fastest search around, but perhaps its not so fast anymore.
Doesn't really matter in most cases, but when you are doing some 1000 searches per module for all modules in a project, time and string table wasted space makes a big difference.
Have been toying with another RegExp search algorithm, where I define the RegExp from the search string and store it in a Skip list. Then if I search for that string again I don't need to define the RegExp (which takes HOPELESSLY, relatively, LONG time).
|